/!\ Caution: do not try it at home, you may suffer severe tunnel effect injuries /!\

This statement may seem familiar to you :

"We want to do scrum, but we are a big and serious company, we can't afford to break prod.
The best way to ensure we don't break anything is to validate each step of our software engineering by architects and managers."

The resulting process looks like that :

• one sprint to play with the foreseen technologies
• one sprint to define the architecture
• two or three sprints to actually write the code
• one sprint for QA to test the application
• one sprint for deployment

With 1-month sprints, that makes 6 months before we deliver anything to production.
It looks more like waterfall than like Scrum.

I guess the main problem is bad MVP definition.
The MVP often includes a lot of security, operability, resiliency, high availability, observability, whatever-y requirements that, while important, may not be needed for a first version.

And what leads to this bad MVP definition is:

1. Lack of trust. I often hear "If we don't do it right now, [they] won't let us do it later."

2. Lack of identification of roles. Who are [they] ? Could we negociate something with them ?

3. Lack of communication with customer. Even when the customer is in the same company, in the next door office, we often consider (without asking them) he won't accept a feature that is not rock-solid, even if delivered as "beta version", a few months before the planned "rock-solid" delivery date.

4. Lack of communication with accountable experts. The architects and various experts that have to validate your architecture just want to make sure you won't break existing features in production. They may accept that new features could be broken under some conditions, but that has to be negociated.

At the end, the missing bits are:

• Individuals and interactions over processes and tools
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• (Working software over comprehensive documentation)

Scrum is useless if we forget the bases: http://agilemanifesto.org/

Altran, mon employeur, m'a invité aux 24HSeries au circuit Paul Ricard (http://www.24hseries.com/2017/24h-circuit-paul-ricard-2017/start), pour suivre la course de la team Altran.

Présentation de la course

C'est donc une course d'endurance de 24H: l'objectif étant, en 24H, d'alligner le plus de tours de circuit possible. La mécanique est très sollicitée, et sur cette épreuve quasiment 1/3 des concurrents n'ont pas réussi à courrir jusqu'à la fin de la course.

Une équipe est constituée principalement de:

• pilotes, qui se relaient au volant toutes les 2H maximum.
• mécaniciens, pour la maintenance aux stands (pneus, freins, et autres)
• équipe de stratégie, dans la salle de télémétrie, qui communiquent avec les pilotes et établissent la stratégie de course
• pompistes, car la pompe à essence n'est pas dans le stand de l'équipe

Les deux voitures du Team Altran sont des 308 RC, de 1100Kg pour environ 310CV. L'équipe courrait avant en 208, et les 308 sont toutes neuves. Elles n'ont fait qu'une course de 12H peu de temps avant. Tous les réglages (chassis, cartographie, transmission…) sont encore jeunes, et l'équipe ne connaît pas encore bien les voitures. 

Début de journée

À partir de 10H, nous avons visité les stands et découvert les voitures. Les mécanos avaient travaillé une bonne partie de la nuit (jusque 4:30 du matin!) pour changer les boites de vitesses, et monter des pièces d'embrayage ajustées en urgence la veille. Au matin, ils effectuaient les dernières vérifications, avant le début des échauffements à 11H.

De 11H à 12H, échauffements. Là, ils se rendent compte que les embrayages ne se comportent pas comme attendu. Investigations en urgence avant le placement sur la grille de départ, prévu à 13H ! Il faut alors identifier la cause (4/10e de mm d'usinage en trop lors de la modif de la veille), déterminer un correctif et appliquer, le tout avant le départ de la course! Timing très tendu, mais ça passe!

À 13H, placement sur la grille de départ, que nous pouvons aller visiter. Là, toutes les équipes hésitent entre les pneus slick et les pneus pluie. En effet la météo est très hésitante. Une grosse averse se déclare avant le départ, mettant tout le monde d'accord pour les pneus pluie.

Pendant la course

Une fois la course démarrée, on pourrait se dire "c'est parti, il n'y a plus qu'à alligner les tours pendant 24H". Si seulement!

Assez rapidement, les voitures rencontrent des problèmes. Les retours que j'ai eu sont assez flous: problèmes de turbo, problèmes de capteur de pression de carburant, ou encore qualité des mousses de réservoir.

J'ai pu observer les mécaniciens en situation d'urgence, agir de manière calme et efficace, investiguer, se partager les tâches, négocier avec l'équipe stratégie pour trouver des solutions sur la durée de la course.

J'ai vraiment apprécié cet aspect de la course, car le parallèle avec mon métier de SRE m'a frappé. Pour faire tenir un site web le temps d'un pic d'audience comme pour faire courrir une voiture pendant 24H, il faut du sang froid, réfléchir vite et trouver des solutions innovantes. Et en tirer des leçons, pour anticiper la prochaine situation de crise.

J'imagine que les équipes du Team Altran rédigent un "post-mortem" retraçant les incidents et avaries de la course, les résolutions tentées et les résultats de ces résolutions.
#teamaltran, si vous me lisez, j'adorerais lire ce document! C'est un aspect de la course qui m'a fasciné!

Quasiment chaque commande Docker de récupération d'informations (comme docker inspect ou docker ps) a une option --format:

--format string   Pretty-print […] using a Go template

Trop peu utilisée, cette commande permet de s'affranchir des post-commandes de formatage cut, grep, awk, sed etc. qu'il faut éviter autant que possible!

Le problème avec les «Go Templates», c'est que la doc de Go n'est pas super parlante si on n'est pas dev Go.

Par contre c'est super bien expliqué dans cet excellent article de prise en main appliqué à Docker:

http://container-solutions.com/docker-inspect-template-magic/

Il y manque juste des exemples d'itération sur tableau avec range, mais c'est couvert en commentaire